In computer networks, a proxy server is a server (which can refer to a physical computer system or a process running thereon) which services the requests of its clients by forwarding requests to other servers. A client (which can also refer to a physical computer system or, more commonly, an application running thereon) connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource, available from a different server known as a backend server. The proxy server (often simply ‘proxy’) provides the resource by connecting to the specified backend server and requesting the service on behalf of the client.
Currently, in a proxy network, failover support between proxies is provided by creating an additional ‘failover’ proxy server that is identical to the first or ‘primary’ proxy server. The proxy servers have no knowledge of each other and must be managed through a process known as a load balancer. A load balancer has a virtual host name that client applications use when sending service requests such as updates to a directory using the Lightweight Directory Access Protocol (LDAP). The load balancer is configured to send those requests to the primary proxy server. If that proxy server is down, or unavailable because of a network failure, the load balancer sends the requests to the failover proxy server until the primary proxy server is back on line and available.
In a load-balanced proxy environment, if the primary proxy server fails, the first request sent to it fails and returns an error. All subsequent requests are sent to the failover proxy server. The first request that failed is typically retried (the “auto-retry” mechanism), but is not necessarily sent to the failover server. This may return an error or corrupt the directory in some failure scenarios. This is explained with reference to the proxy network 100 illustrated in FIG. 1.
In FIG. 1, the proxy server 130 is the primary proxy to which the requests are routed and proxy server 140 is the failover proxy. In such a situation, the normal flow of requests from the client 110 is client 110->load balancer 120->primary proxy server 130->one of the backend servers 150, 170 (as illustrated, 150 ), each of which services a database 160, 180 respectively. This flow of requests is shown by arrows 101, 102 and 103 respectively. The normal flow of response would be backend server 150->primary proxy server 130->load balancer 120->client 110, as shown by the arrows 104, 105 and 106 respectively. If the primary proxy 130 fails, the request would be routed to the failover proxy server 140 and thence to backend server 150. The flow of request and response in the failover scenario is shown using dashed arrows 102a, 103a, 104a and 105a. 
Now assume that client 110 has issued a LDAP Modify request to alter database 160. The load balancer 120 has forwarded that request to the primary proxy server 130 which has in turn forwarded it to backend server 150 and the request is outstanding, in the sense that backend server 150 is still processing the request and is yet to send the response back. In such a situation, if the primary proxy server 130 fails, then load balancer 120 will get an error, either by timing out while waiting for a response, or as a result of a periodic polling action. The request will then be retried with the failover proxy server 140. So the following things may happen because the same request will be processed twice by the same backend server 150:                In the case of LDAP ADD requests, the client 110 will get an LDAP_ALREADY_EXISTS error.        In the case of LDAP DELETE requests, the client 110 will get an LDAP_NO_SUCH_OBJECT error.        In case of LDAP MODIFY requests, the database 160 may get corrupted.        